MultiJava: Design Rationale, Compiler Implementation, and User Experience

class Component { abstract void handleEvent(Event e); }void handleEvent(Event e); } Fig. 30. Base class of components in an event-based system sending messages to one another. Instead, each component is able to announce a set of events. Separately, other components can register to receive notification whenever a certain event is announced by providing a handler procedure for the event. When an event is announced, the system invokes all the handlers that are associated with that event. The canonical example of an event-based system is a GUI. Events are announced in response to user actions (e.g., clicking a button), and these events trigger the appropriate actions of components (e.g., updating the display). Java’s Abstract Windowing Toolkit (AWT) is a library for building GUIs that employs the event-based style. Several of the projects in our user community employ event-based architectures. The GUI for the reconfigurable chip is built on top of AWT. The event-based style is also used by all of the ubiquitous systems described earlier. In the ubiquitous systems, extensibility is at a premium: it must be possible for new components to easily join and leave the system dynamically. The event-based style facilitates this extensibility by keeping components loosely coupled, since components communicate only indirectly through events. 5.1.2.1 Basic Event Dispatching. In the context of an object-oriented language like Java, an event-based system typically includes an abstract class or interface that defines the required functionality of all components, as shown in Fig. 30. Each component is a concrete subclass of Component, and each event is similarly a subclass of an abstract Event class. A component’s handleEvent method is its event handler: when an event occurs, the components that have registered for that event are notified by having their handleEvent methods invoked, passing the announced event as an argument. The handleEvent operation is a natural application for multiple dispatch in MultiJava. The functionality for handling an event depends both on which component is handling the event and on which event has been announced, but Java only allows one of these hierarchies to be dispatched upon. Therefore, programmers must manually dispatch on the other hierarchy, usually via run-time type tests and casts. An example of Java and MultiJava event handlers in a hypothetical GUI for a text editor is shown in Fig. 31. The benefits of MultiJava illustrated for binary methods are accrued to an even greater extent in the context of event handling. MultiJava allows each conceptual handler to be encapsulated as its own method, rather than buried in an if case of one monolithic method. Users report that this style of implementing handlers exactly matches their high-level view of a component as containing a set of handlers, each handling a particular event. The header of each multimethod characterizes the conditions under which that handler will be invoked, and static checking ensures that there is a most-specific applicable handler for each possible event. As a simple example of static checking, the lack of a default handler accepting any Event would ACM Transactions on Programming Languages and Systems, Vol. TBD, No. TDB, Month Year.